home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group95a.txt / 000036_icon-group-sender _Mon Jan 30 15:36:49 1995.msg < prev    next >
Internet Message Format  |  1995-02-09  |  5KB
  1. Received: by cheltenham.cs.arizona.edu; Mon, 30 Jan 1995 09:37:21 MST
  2. To: icon-group-l@cs.arizona.edu
  3. Date: Mon, 30 Jan 1995 15:36:49 GMT
  4. From: goer@quads.uchicago.edu (Richard L. Goerwitz)
  5. Message-Id: <1995Jan30.153649.11735@midway.uchicago.edu>
  6. Organization: University of Chicago
  7. Sender: icon-group-request@cs.arizona.edu
  8. References: <3geb4t$cfn@magnum.convex.com>, <3gg0cv$jv8@hahn.informatik.hu-berlin.de>
  9. Reply-To: goer@midway.uchicago.edu
  10. Subject: Unicode (was Re: Linux, HPFS, and internationalization)
  11. Errors-To: icon-group-errors@cs.arizona.edu
  12.  
  13. I'm cross-posting to the Icon newsgroup, because of the recent discussion
  14. there of Unicode and internationalization issues.  Followups, though, are
  15. directed back to comp.os.linux.development.system:
  16.  
  17. In article loewis@informatik.hu-berlin.de (loewis) writes:
  18. >
  19. >In general, I believe internationalization efforts of Linux should 
  20. >introduce Unicode wherever reasonable - file names is one of the places.
  21. >The question about sorting now is still: according to what rules. When
  22. >displaying information to the user, you would like to follow the sorting
  23. >rules of the user's native language. In the file system, all that counts
  24. >is that you never lose accessability, as you point out. These are two
  25. >different things, though.
  26.  
  27. I think that this was IBM's idea when tagging directory entries for
  28. code page.  They wanted different sort orders for different "locales"
  29. (in this case identified with codepages).  Just a hunch.
  30.  
  31. One of the problems with Unicode, incidentally, is that despite all the
  32. hoopla, information about it is being disseminated very, very slowly.
  33. And it is doubtful that Unicode will ever displace standards like Shift-
  34. JIS in Asia.  Also, note that if localization is a concern (as in the
  35. above posting), Unicode isn't a cure-all.  Unicode is kind of a super-
  36. ISO 8859-1 in the sense that it doesn't tell you what language or locale
  37. you're in.  So, for example, if I run into an Arabic alif in Unicode,
  38. I really don't know whether I'm looking at Arabic, Persian, or Urdu.
  39. The problem is the same for the so-called "CKJ" languages, Chinese,
  40. Korean, and Japanese.
  41.  
  42. This would be a good time for someone who's worked on Plan 9 to jump
  43. in with advice.  What would be a sensible way of migrating to Unicode
  44. or other standards?  Do we use UTF-8 (about which information is even
  45. harded to come by than Unicode)?  Or do we use some form of wide char
  46. I/O, using straight Unicode?  Or do we default to UTF-8 for backwards
  47. compatibility, but provide facilities for straight Unicode?
  48.  
  49. As usual, I must confess that I'm not a software engineer.  I'm in Near
  50. Eastern Languages.  But I'm following this group because the Linux
  51. community seems unusually responsive to internationalization issues, at
  52. least on the discussion level.  (Apps. don't seem to be moving along
  53. in this direction.)  Part of the problem is that information isn't all
  54. that widely disseminated (at least in the US) about how other scripts
  55. and encoding systems work.  Programmers just don't have the basic info
  56. they need.  And few Americans understand how Asian or Middle Eastern
  57. or Indian scripts work (the bidirectional wordwrap algorithm, for ex-
  58. ample, baffles many of them - not because they're dumb, but because of
  59. simple lack of exposure to Arabic, Hebrew, etc.).
  60.  
  61. As a first step, everyone ought to peruse the comp.software.internation-
  62. alization FAQ, which at least sets forth how to use ANSI C setlocale.
  63. A second step is to buy the Unicode manual, now out of date (but still
  64. useful enough):
  65.  
  66.   The Unicode Standard Version 1.0
  67.   two volumes
  68.   Addison Wesley, 1990,91
  69.  
  70. At the end of that volume is a horrendous account of the bi-di wordwrap
  71. algorithm that is guaranteed to mystify anyone who has not studied Arabic
  72. and/or Hebrew.  If anyone gets this far, and wants clean, simple info,
  73. please contact me directly.  I'll post my own informal, programmer ori-
  74. ented description of the bidi algorithm if asked.
  75.  
  76. For UTF-8, check out http://www.stonehand.com/unicode/standard/utf8.html.
  77. Basically, it works as follows:
  78.  
  79.  * Bits  Hex Min  Hex Max  Byte Sequence in Binary
  80.  *   7  00000000 0000007f 0vvvvvvv
  81.  *  11  00000080 000007FF 110vvvvv 10vvvvvv
  82.  *  16  00000800 0000FFFF 1110vvvv 10vvvvvv 10vvvvvv
  83.  *  21  00010000 001FFFFF 11110vvv 10vvvvvv 10vvvvvv 10vvvvvv
  84.  *  26  00200000 03FFFFFF 111110vv 10vvvvvv 10vvvvvv 10vvvvvv 10vvvvvv
  85.  *  31  04000000 7FFFFFFF 1111110v 10vvvvvv 10vvvvvv 10vvvvvv 10vvvvvv 10vvvvvv
  86.  *
  87.  * The UCS value is just the concatenation of the v bits in the multibyte
  88.  * encoding.  When there are multiple ways to encode a value, for example
  89.  * UCS 0, only the shortest encoding is legal.
  90.  
  91. The idea is that no UTF-8 sequence can be confused with ASCII codes, since
  92. the first 128 places (if I understand correctly) constitute a compatibility
  93. zone.  Note that some space is lost in storage, but compression takes care
  94. of this nicely.  Internally, one can use whatever one pleases (16-bit
  95. chars are sufficient for Unicode).
  96.  
  97. I hope this helps.  The Linux community is an interesting, energetic
  98. bunch.
  99.  
  100.  
  101. -- 
  102.  
  103.    Richard L. Goerwitz     ***      goer@midway.uchicago.edu